This updates our Unity code gen to add partial classes that create a RequireComponent dependency from the "host" behavior (the MonoBehavior on which the [RGState] or [RGAction] attribute is placed) to the generated RGState_[HostBehaviorName] and RGAction_[HostBehaviorName] components. This signals to the Unity editor, when reimporting assets, to add the RGState_.../RGAction_... components to any GameObject that also has the host behavior attached. This mostly allows us to "auto-attach" the behaviors.

From my testing, this is fairly consistent. Unity does caution that it doesn't check dependencies in all scenarios, but it does it whenever GameObject.AddComponent is called.

In order to generate this auto-attach class, we need the original host behavior to be marked as a partial class. I added code to check for that and report an error if that's not the case. WIth the changes in #105, this also causes a dialog to pop up to draw your attention to the log:

NOTE: One additional change I made is to restore the "Generate Scripts" menu item. After #105 merged, auto-generation is mostly working but there are a few scenarios where I've noticed it doesn't work:

1. If you change anything in the RegressionGames packages, it doesn't re-generate. This mostly affects us
2. If you delete or otherwise mess with the generated code (perhaps accidentally).

Both cases are fairly rare (case 1 is mostly just for us), but it seems reasonable to me to bring back the ability to manually regenerate the scripts, even if it's only needed in edge cases.

Find the pull request instructions here

Every reviewer and the owner of the PR should consider these points in their request (feel free to copy this checklist so you can fill it out yourself in the overall PR comment)

• The code is extensible and backward compatible
• New public interfaces are extensible and open to backward compatibility in the future
• If preparing to remove a field in the future (i.e. this PR removes an argument), the argument stays but is no longer functional, and attaches a deprecation warning. A linear task is also created to track this deletion task.
• Non-critical or potentially modifiable arguments are optional
• Breaking changes and the approach to handling them have been verified with the team (in the Linear task, design doc, or PR itself)
• The code is easy to read
• Unit tests are added for expected and edge cases
• Integration tests are added for expected and edge cases
• Functions and classes are documented
• Migrations for both up and down operations are completed
• A documentation PR is created and being reviewed for anything in this PR that requires knowledge to use
• Implications on other dependent code (i.e. sample games and sample bots) is considered, mentioned, and properly handled
• Style changes and other non-blocking changes are marked as non-blocking from reviewers